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(54) Packet distribution in a microcomputer 

(57) An integrated circuit device (11) with an ad- 
dress and data path (15) interconnects a CPU (12) with 
at least one module (14) and a memory interface (32), 
the module (1 4) having circuitry (8) to generate an event 



request packet and the CPU having event logic (44) to 
decode the packet as well as circuitry to generate ad- 
dressed memory access packets, the same address 
and data path (15) being used for the distribution of 
event request packets and memory access packets. 
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Description 

[0001] The invention relates to microcomputers, computer systems and methods of operating such. 
[0002] Microcomputer chips may include a CPU with a plurality of other modules as well as a memory interface on 
s the same chip. The CPU as well as other modules may need to carry out memory access operations in order to effect 
read and write operations. Furthermore, some modules on the chip may need to generate interrupt requests to vary 
to routine operated by another device on the chip and in some cases it may be necessary to provide control commands 
to which an on-chip CPU must respond. 

[0003] It is an object of the present invention to provide an improved computer system and method of operating a 
io computer system for distributing memory access requests and other requests on a chip. 

[0004] The invention provides a computer system including an integrated circuit chip with an address and data path 
interconnecting a plurality of on-chip devices including at least one CPU, at least one module and a memory interface, 
(a) said module having packet generating circuitry responsive to an event to generate an event request packet including 
a destination address, (b) said CPU having event logic to decode the packet and identify the request of the packet, 
is and circuitry to generate addressed memory access packets, and (c) said address and data path being used for dis- 
tribution of both event request packets and memory access packets. 

[0005] Preferably both said module and said CPU each include packet generating circuitry operable to generate both 
event request packets and memory access packets for distribution on the common address and data path. 
[0006] Preferably tbe packet generating circuitry is responsive to receipt of an event request packet to generate an 
20 addressed response bit packet for distribution on said address and data path. 

[0007] Preferably the packet generating circuitry of a module includes means to indicate the address of the destination 
for the packet as well as the address of the module acting as a source of the packet. 

[0008] Preferably the packet generating circuitry is responsive to receipt of an event request packet to determine 
from the packet a source address of the packet and to generate a response packet using said source address as the 
25 destination indicator for the response packet. 

[0009] The system may include an on-chip memory, said memory interface providing connection between said ad- 
dress and data path and said on-chip memory. 

[0010] The system may include an off-chip memory, said chip having an external memory interface connected to 
said off -chip memory and to said address and data path. 
30 [001 1] The packet generating circuitry of said module may be arranged to generate an event request packet forming 
an interrupt request with a priority indicator and said event logic of the CPU includes comparator circuitry for comparing 
priorities of event request packets received with the priority of any current CPU activity. 

[0012] The packet generating circuitry of said module may be arranged to generate an event request packet in the 
form of a control packet for control command to the CPU. 
3S [001 3] Preferably a plurality of modules are provided on chip, each having packet generating circuitry for generating 
event request packets, at least one module being arranged to generate event packets in the form of prioritised interrupt 
requests and at least another module being arranged to generate event request packets in the form of control packets 
for the CPU. 

[0014] Preferably said address and data path includes at least one on-chip bus arranged to distribute said packets 
40 \n bit parallel format. 

[0015] Preferably said integrated circuit chip includes at least one external port for off -chip connection, said port 
including bit format translation circuitry to convert on-chip packets of bit parallel format to a less parallel format for 
transmission off-chip. 

[0016] The invention also provides a method of operating a computer system comprising an integrated circuit chip 
45 with an address and data path interconnecting a plurality of on-chip devices including at least one CPU, at least one 
module and a memory interface, which method comprises detecting an event at a module, generating an event request 
packet with a destination address, distributing the request packet on the address and data path to the destination, 
decoding the packet at the destination to identify the nature of the request, said method further including generating 
addressed memory access packets for memory read and write operations : said memory access packets and said event 
so request packets being distributed on the same address and data path, 

[0017] Preferably event request packets are generated for distribution on the address and data path to the CPU, 
which event request packets are in the form of prioritised interrupt requests. 

[0018] Preferably event request packets are generated for distribution on said address and data path to the CPU, 
at least some of said event request packets being in the form of control command packets to which the CPU must 
55 respond on receipt of the packet. 

[0019] An embodiment of the present invention will now be described by way of example with reference to the ac- 
companying drawings in which: 
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Figure 1 is a block diagram of a microcomputer chip in accordance with the present invention, 
Figure 2 shows more detail of a debug port of the microcomputer of Figure 1 , 
s Figure 3 shows input of a digital signal packet through the port of Figure 2, 

Figure 4 shows the output of a digital signal packet to the port o1 Figure 2, 
Figure 5 shows accessing of registers in the port of Figure 2, 

10 

Figure 6 shows the format of a digital signal request packet which may be used in the microcomputer of Figure 1 , 
Figure 7 shows the format of a digital signal response packet which may be used in the microcomputer of Figure 1 , 
is Figure 8 shows one example of a serial request packet which may be output or input through the port of Figure 2, 

Figure 9 illustrates further details of one CPU of the microcomputer of Figure 1 including special event logic, 
Figure 10 shows further detail of the special event logic of Figure 9, 

20 

Figure 11 shows a microcomputer of the type shown in Figure 1 connected to a host computer for use in debugging 
the CPU by operation of the host, 

Figure 12 shows an arrangement similar to Figure 11 in which a second CPU is provided on the same chip and 
25 operates normally while the other CPU is debugged by the host 

Figure 13 illustrates one CPU forming part of a microcomputer as shown in Figure 1 when connected to a host 
computer for use in watchpoint debugging, 

30 Figure 14 shows a microcomputer of the type shown in Figure 1 connected to a host computer in which one CPU 

on the microcomputer is debugged by the other CPU on the same chip, 

Figure 1 5 shows more detail of part of the logic circuitry of Figure 1 0, 

35 Figure 1 6 shows more detail of part of the logic circuitry of Figure 1 5, 

Figure 17 shows more detail of another part of the logic circuitry of Figure 1 5.. and 

Figure 18 shows a block diagram of three interconnected integrated circuit CPU devices in accordance with the 
40 invention, 

Figures 19 to 24 show different bit packet formats for distribution on the address and data paths of the devices 
shown in Figures 1 and 18, 

45 Figure 25 shows more detail of event handling circuitry in a CPU of the type shown in Figures 1 and 1 8, 

Figure 26 shows a priority comparator used in the CPU's of Figures 1 and 18, and 

Figure 27 shows an event logic and packet generator for use in modules connected to the data and address path 
50 of the devices shown in Figures 1 and 18. 

[0020] The integrated circuit devices of this embodiment are illustrated in Figures 1 and 18. Figure 1 shows a single 
chip whereas Figure 1B shows three chips interconnected through external ports 30 by wires 10 carrying serial bit 
packets. On each chip 11 a CPU 1 2 is connected to a plurality of modules 14 by a data and address path 1 5 arranged 
55 to carry bit packets in parallel form. The modules 1 4 as well as the CPU 1 2 include event logic used in the distribution 
of bit packets on the path 15. Three types of packet are used on the data and address path 15, each including a 
destination indicator to indicate the required destination device connected to the path 15. The packets include data 
transfer packets which are necessary for memory access operations. In addition there are event packets of two types. 
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Normal event packets form prioritised interrupts which may be received the CPU or module with the recipient selectively 
deciding whether, or when, to respond to the event packet depending on relative priority with other activities requested 
at that device. Special ev nt packets form command control signals which must be acted on by the recipient device 
when the special event packet is received. In this embodiment modules 1 4 as well as the CPU 1 2 have event logic for 
$ handling event packet formation and receipt including normal events acting as interrupt requests as well as special 
events acting as control commands. In the example shown in Figure 18 each chip 11 includes on-chip memory as well 
as off-chip memory 1 20. Although in Figure 1 8 each chip includes a single CPU 1 2 more than one CPU may be provided 
on the same chip as shown in Figure 1. 

[0021] The preferred embodiment illustrated in Figure 1 comprises a single integrated circuit chip 11 on which is 
10 provided two CPU circuits 1 2 and 1 3 as well as a plurality of modules 1 4. The CPU's 1 2 and 1 3 as well as each module 

14 are interconnected by a bus network 15 having bi-directional connections to each module. In this example the bus 
network is referred to as a P-link consisting of a parallel data bus 20 as shown in Figure 2 together with a dedicated 
control bus 21 provided respectively for each module so as to link the module to a P-link control unit 22. Each module 
is provided with a P-link interface 23 incorporating a state machine so as to interchange control signals between the 

15 respective P-link control line 21 and the interface 23 as well as transferring data in two opposing directions between 
the data bus 20 and the interface 23. 

[0022] In the example shown in Figure 1, the various modules 14 include a video display interface 25 having an 
external connection 26, a video decode assist circuitry 27, an audio output interface 28 having an external connection 
29, a debug port 30 having an external connection 31 , an external memory interface 32 having an external bus con- 

20 nection 33 leading to an external memory, clock circuitry 34, various peripheral interfaces 35 provided with a plurality 
of bus and serial wire output connections 36, a network interface 37 with an external connection 38 as well as the P- 
link control unit 22. The two CPU units 1 2 and 1 3 of this example are generally similar in construction and each includes 
a plurality of instruction execution units 40, a plurality of registers 41 an instruction cache 42 and a data cache 43. In 
this example each CPU also includes event logic circuitry 44 connected to the execution units 40, and the other modules 

2B connected to the P-link each include event logic 8 for handling both normal event and special event packets. The P- 
link 15 is arranged to transmit to modules on the link and to the external memory interface both request and response 
packets, including memory access transactions, interrupts in the form of normal events, and control signals in the form 
of special events. These packets may be generated by software as a result of instruction execution by a CPU or by 
hardware responsive to detecting of an event. The packets may be generated on chip and distributed on the link 15 

30 or generated off chip and supplied to the on chip link 1 5 through an external port such as the debug port 30. 

[0023] The CPU's can be operated in conventional manner receiving instructions from the instruction caches 42 on 
chip and effecting data read or write operations with the data cache 43 on chip. Additionally external memory accesses 
/ for read or write operations may be made through the external memory interface 32 and bus connection 33. The debug 
port 30 is described in more detail in Figures 2 to 5. As shown in Figure 2, this circuitry includes a hard reset controller 

35 45 connected to a hard reset pin 46. The controller 45 is connected to all modules on the chip shown in Figure 1 so 
that when the hard reset signal is asserted on pin 46 all circuitry on the chip is reset. 

[0024] As will be described below, this port 30 provides an important external communication which may be used 
for example in debugging procedures. The on-chip CPU's 12 and 13 may obtain instruction code (by memory access 
packets) for execution from an external source communicating through the port 30. Furthermore, event packets pro- 
40 viding either interrupts or control signals may be put onto the P-link 15 from an external chip via the port 30. Commu- 
nications on the P-link system 15 are carried'out in bit parallel format. Transmissions on the data bus 20 of the P-link 

1 5 may be carried out in multiple byte packets, for example 35 bytes for each packet, so that one packet is transmitted 
in five consecutive eight byte transfers along the P-link each transfer being in bit parallel format. The port 30 is arranged 
to reduce the parallelism of packets obtained from the P-link 15 so that they are output in bit serial format through the 

45 output 31 or alternatively in a much reduced parallel format relative to that used on the P-link 15 so as to reduce the 
number of external connection pins needed to implement the external connection 31. 
[0025] The structure of the port 30 will now be described with reference to Figures 2 to 5. 

[0026] In this example the port 30 comprises an outgoing packetising buffer 50 connected to the P-link interface 23 
as well as an incoming packetising buffer 51 connected to the interface 23. On the output side, the external connection 

50 31 is in this case formed by an output pin 52 and an input pin 53. The port in this case effects a full transition between 
parallel format from the data bus 20 to bit serial format for the input and output pins 52 and 53. The pins 52 and 53 
are connected as part of an output link engine 55 which also incorporates serialiser 56 and de-serialiser 57 connected 
respectively to the outgoing packetising buffer 50 and the incoming packetising buffer 51 . Between the buffers 50 and 
51 are connected by bidirectional connections a register bank 58 and a port state machine 59. The function of the port 

55 30 is to translate bit packets between the internal on-chip parallel format and the external bit serial format. In addition 
it allows packets which are input through pin 53 to access the registers 58 in the port without use of the P-link system 
15. Equally packets on the P-link system 15 can access the registers 58 of the port without using the external pins 52 
or 53. 
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[0027] The format of the multibit packets used on the P-link system 15 in the microcomputer are illustrated by way 
of example in Figures 6, 7 and 8. Figures 6 and 7 show packet formats used in parallel form on the P-link whereas 
Figure 8 shows a packet similar to that of Figur 6 including a length indication when the packet is in serial form. When 
a packet is to be output from the port 30 from one of the modules 14 connected to the P-link 15, the module transmits 

s the parallel representation of the packet along the data bus 20. The packet may comprise a plurality of eight byte 
transfers as already described. Each module 14, including the port 30, have a similar P-link interface 23 and the op- 
eration to take data from the bus 20 or to put data onto the bus 20 is similar for each. When a module has a packet to 
send to another module, for example to the port 30, it first signals this by asserting a request signal on line 60 to the 
dedicated link 21 connecting that module to the central control 22. It also outputs an eight bit signal on a destination 

io bus 61 to indicate to the control the intended destination of the packet it wishes to transmit. It will be understood that 
the P-link 21 is itself a bus. A module such as the port 30, which is able to receive a packet from the bus 20 will assert 
a signal "grant receive" on line 62 to be supplied on the dedicated path 21 to the central control 22 regardless of whether 
a packet is available to be fed to that destination or not. When the central control 22 determines that a module wishes 
to send a packet to a destination and independently the destination has indicated by the signal on line 22 that it is able 

15 to receive a packet from the bus 20, the control 22 arranges for the transfer to take place. The control 22 asserts the 
'grant send" signal 63 via the dedicated line 21 to the appropriate interface 23 causing the sending module to put the 
packet onto the P-link data path 20 via the bus 64 interconnecting the interface 23 with the data bus 20. The control 
22 then asserts the "send" signal 65 of the receiver which signals to it that it should accept the transfers currently on 
the P-link data bus 20. The packet transmission concludes when the sender asserts its -"end of packet send" line 66 

20 concurrently with the last transfer of packet data on the bus 20. This signal is fed on the dedicated path 21 to the central 
control 22 and the control then asserts the "end of packet received' signal 67 to the receiving module which causes it 
to cease accepting data on the P-link data bus 20 after the current transfer has been received. 
[0028] The parallel to serial translation which takes place in the port 30 has a one to one equivalence between the 
parallel and serial packets so that all data contained in one packet form is contained in the other. The translation 

25 therefore involves identifying the type of the packet and copying across fields of the packet in a manner determined 
by the type. When a packet is input to the outgoing packetising buffer 50 from the data bus 20, the packet is held in 
its entirety as the buffer is 35 bytes long in order to hold the longest packet. As shown in Figure 4, buffer 50 is connected 
to the port state machine 59 and to a shift register 70 by a transfer bus 71. The shift register 70 is connected to the 
seriaiiser 56. The state machine 59 provides input signals 72 to the buffer 50 to copy specific bytes from the P-link 

30 packet ontothe transfer bus 71 under the control of the state machine59. Firstly the most significant byte of the packet, 
which holds the destination header 73, is placed onto the byte wide transfer bus 71 . The state machine 59 compares 
this value with those values which indicate that the packet is destined for the shift register and output serial link. If the 
packet is destined for the output serial link, the state machine causes the next byte 74 of the packet (which is the 
operation code indicating the type of packet) to be placed on the transfer bus 71 . From the opcode 74 which is supplied 

35 to the state machine 59 on the transfer bus 71, the state machine determines the length and format of the packet 
derived from the data bus 20 and therefore determines the length and format of the serial packet which it has to 
synthesise. The state machine 59 outputs a byte which indicates the serial length packet onto the transfer bus 71 and 
this is shifted into the first byte position of the shift register 70. The state machine 59 then causes bytes to be copied 
from the buffer 50 ontothe bus 71 where they are shifted into the next byte position in the shift register 70. This continues 

40 until all the bytes from the buffer 50 have been copied across. The order of byte extractions from the buffer 50 is 
contained in the state machine 59 as this determines the reformatting in serial format The serial packet may then be 
output by the output engine 55 via pin 52 to externally connected circuitry as will be described with reference to Figures 
11 to 14. 

[0029] When a serial packet is input through pin 53 to the port 30, the translation is dealt with as follows. Each byte 
45 js passed into the shift register 80 forming a packetising buffer. Such a serial packet is shown in Figure 8 in which the 
first byte 81 indicates the packet size. This will identify the position of the last byte of the packet. Referring to Figure 
3, the register 80 copies bytes in the simple order they are shifted out of the shift register onto a transfer bus 83 under 
the control of the state machine 59. The state machine 59 compares the destination byte 84 of the packet with those 
values which indicate that the packet is destined for the P-link system 1 5. The state machine 59 causes the next byte 
50 85 of the packet to be placed on the transfer bus in order to indicate the type of packet (also known as the opcode) 
and from this the state machine checks the length and format of the serial link packet and those of the P-link packet 
which it has to synthesise. The state machine 59 causes bytes to be shifted out of the register 80 onto bus 83 where 
they are copied into a P-link packet buffer 51. This continues until all serial link bytes have been copied across and 
the positions in which the bytes are copied into the buffer 86 from the shift register 80 is determined by setting of the 
55 state machine 59. This indicates to the interface 23 that a packet is ready to be put on the bus 20 and the interface 
communicates through the dedicated communication path 21 with the central control 22 as previously described. When 
the P-link system 1 5 is ready to accept the packet the interface responds by copying the first eight bytes of the packet 
onto he data path 20 on the following clock cycle (controlled by clock 34). It copies consecutive eight byte parts of the 
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The instruction set will include a plurality of conventional instructions for a microcomputer, such as load and store used 
for memory accesses, but this example also includes an instruction to send an ' vent" packet. An "event" is an xcep- 
tional occurrence normally caused by circumstances external to a thread of instructions. An event packet may be sent 
by execution of an event instruction although hardware in the form of the event logic in any module connected to the 

5 P-link may generate some events and event packets without the execution of instructions in a service or handler routine. 
[0037] Events which originate from execution of an instruction by a CPU are caused by execution of the event in- 
struction. This can be used to send an "event" to a CPU such as one or other of the CPU's 12 or 13 on the same chip 
or it may be used to send an event to a CPU on a different chip through an external connection. The CPU which 
executes the event instruction may also send an event to a further module connected to the P-link system 15. The 

10 event instruction has two 64 bit operands, the event number and the event operand. With regard to the event number 
0-63, bit 15 is used to determine whether or not the event is a "special event'. A special event is used in a control 
signal packet to which a recipient module or CPU must respond regardless of the priority level at which the CPU is 
currently operating. When bit 15 is set to 1 s bits 0-14 are used to define the type of special event. Bits 16-63 of the 
event number are used to identify the destination address of the CPU or module to receive the special event. The bit 
numbers referred to above in the event number may be mapped to different locations in the packet as shown in Figure 
• 6. For example, the opcode identifying the packet as an event request will be located at byte position marked 74 in 
Figure 6 but the bits determining the type of event (EN code) will be positioned in the address section 100 as this is 
not needed for extra address indication in the case of an event packet, The types of special event are set out below: 



20 


I Event Name 


EN.CODE 


EN.OPERAND 


Function ^H! 




EVENT. RUN 


1 


Ignored 


Resumes execution from suspended state of 
the receiving CPU 


25 


EVENT. RESET 


3 


Ignored 


Generate a reset event on the receiving CPU j 


EVENT.SUSPEND 


5 


Ignored 


Suspends execution of the receiving CPU | 




EVENT.SET RESET.HANDLER 


7 


boot address 


RESET. HANDLER SHADOW <- RESET I 
HANDLER j 
RESET.HANDLER <- boot address J 



[0038] These special events may be sent from one CPU 12 or 13 to the other or alternatively they may be sent 
through the debug port 30 from an external host to either of the CPU's 1 2 or 1 3 on chip. The "event" will be sent as a 
bit packet of the type previously described. 

[0039] In response to a special event, which acts as a CPU control packet, either CPU 12 or 13 can be made to 
& cease fetching and issuing instructions and enter the suspended state. 

[0040] When an EVENT.SUSPEND is received by a CPU it sets a suspend flag This flag is OR-ed with the state of 
the suspend pin to determine the execution stage of the CPU. 
[0041] The suspended state may be entered by: 

<*° • Asserting the SUSPEND PIN> This stops all CPUs on the chip. 

• Sending an EVENT.SUSPEND to a CPU. This suspends only the receiving CPU. 
[0042] The suspended state may be exited by either of: 

45 

• Changing an external SUSPEND PIN from the asserted to negated stage. This causes all CPU(s) which do not 
have their suspend flags set to resume execution. 

• Sending an EVE NT. RUN special event to a CPU. This clears the suspend flag. If the SUSPEND PIN is negated 
50 this causes the receiving CPU to resume execution. 

[0043] Entering the suspended state causes a CPU to drain the execution pipelines. This takes an implementation 
defined period of time. While a CPU is suspended its execution context may be changed in any of the following ways: 

55 • The reset address control register RESET.HANDLER may be changed. 

• The CPU may be reset. 
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♦ External memory may be changed by DMA. e.g. using the debug link 30. 
s j^™ edgeofthe 

[0046] The .nstruction execution system for CPU 12 or 13 , V *** P ' aC9 - 

- descnbec, with reference to Figure 9 In normal operat ion the C^ut h " T ** SPeda ' '° 9ic Uflrt 44 be 

;;; e,ch ; ( ' 01 re,rievas ^ons ^ »• £££ II 22 S T cu . te instruction cyc,e is as f °»°^ 

buffer ready for decoding by a decode unit 102. The Se unit ,« ? J ' nStfUC,lons are ali 9^d and placed in a 
or execute. A despatcher circuit 103 controls and decTdfs vTch Z 8<a ". dard,ses •» '°™a< of instructions suitable 
.ns.ruct.ons atong with any operands to the execrtbn unfiolo^ I ^ ^ ^ f ° 6XeCUted and iss ^s the 
" embodiment has in addition the special event logic 44 This u ^t L e S» ! 1 ^ Th6 micro «™P"ter chip of this 
on the P.| (nk system 15 through the interface 23 sc^s S 

of an -event suspend' packet the specfel event ^Mm^Z^I T"*™ fetCh sec > uence - Receipt 
and cause the despatcher 103 to cease despatching instructions tZ P 1 ° 1 ,0 C6ase fe,chin ° '^ructions 

a ™<™"packetwillcause^^ 

*e suspend pin is not asserted. In addition to stopp^g or^l nol feSUme ,9tenin 9 instructfons provided 

[0048] Figure 10 shows t^nJ^S^^^^.^ feference ,0 ^ 1* 
As >s shown in more detail in Figure 10. t2^XT£2£2!LS 23 10 the P * k s ^em 15. 

which compnses in more detail the following components Z ^evenfh^T 9 3 bUS "° ,0 the Special event ^ 44 
° the ™tmctionfetch^^^ 

to event logic circuitry 114 which has a bi^ona^ 10a The bus 1 10 * also connected 

5J- com munition with £e even, £ J ~^sh£ J™ ^ 

a desunatron .ndicator identifying the moduli .shown in Figu re In Z * T™^ 0 " ^ P "' nk System 1 5 "^ng 
23 along bus 110 to the event hand|ef " FJu^ 0_ In that case the packet is taken through the interface 

loo^e^ 

to as the suspend state. „ the arrival of the ^^^^^^t^^ 114 The reSUtt is re,erfed 
done " ,f the amval of the "event suspend" has cnanoS th! c T 9 the SUSpend s,ate ™™ng further 
accessing of instructions from the cache 42 1,^^^ ^^ ^ 6Vent lo 9 ic 114 ™*>«* £ 

of .nstructions by the fe.cher 101 and the despatc ^onnstmctioT^ h h handbr 111 wW * contro,s ***n fl 
rece.pt ol the "event suspend" will be completed ^but the CpS E£? despatcher 103. Instructions fetched prior to 
a state where no instructions are being feiched o^xecuSd ^ ** * 6 ^ 114 wi " eve ^l.y enter 

LiormrS^ 

suspend state. If the arrival of the "event run" ha in?I? 1 1 SUSpend p,n 1ia The resu 't is known as the 
arrivalof the "even, run" has changed u^ltZT * T™* "* ^ no,hin 9 furth - is doTe f ne 
from tne cache 42. A signal passed throug h 

O0S 2 7 T n f h " eXeCUte <* c,e a < the ^nt a, which C su ; pe " d T * * * **** ^ *" lhe CPU 

m T 11 9 , is put into the shadow 11 9 and the previous value ,hat w ^ 

--on se q uencewhosefirst instruct 
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new address Is obtained on line 120 through the event logic 114 to the event handler 111 prior to being supplied to the 
(etcher 101. 

[0054] It will therefore b seen that by use of the special events which may be indicated in a packet on the P-link 
system 15, sources on-chip or off-chip may be used to suspend the fetching and execution of instructions by a CPU 
or to resume execution of a suspended CPU. It may also be used to reset a CPU into an initial state or to provide a 
new boot code for the CPU from anywhere on the P-link system or anywhere in an interconnected network using the 
external port 30 so that it forms part of the physical address space throughout the network which may be accessed by 
the CPU. 

[0055] More detailed Figures showing the special event logic 44 are provided in Figures 15, 16 and 17. Figure 15 
shows the P-link system 1 5 including a Receive buffer 1 40 and a Transmit buffer 1 41 adjacent the interface 23. When 
a packet including a special event is received in the buffer 140, inputs maybe provided on lines 142, 143 and 144 to 
special event decode logic 145. When bit 15 of the event number is set to 1 thereby indicating a special event, a P 
valid signal is provided on line 142 to the decode logic 145. At the same time the event code field of the packet is 
supplied on line 143 to the decode logic 145 and the event operand field is supplied on line 144 to the decode logic 
145. In response to assertion of the P valid signal on line 142, the decode logic 145 decodes the event code field as 
indicated in the following table; 



P_en.code 


Signal asserted 


Ev_handle 


001 


Ev_run 




011 


Evjeset 




101 


Ev_Susp 




111 


Ev_set 


P_en.op 



[0056] On the cycle of operations following decoding, the decode logic 145 outputs a signal on line 1 46 P Event 
done to clear the buffer 140. Depending on the result of decoding the signal on line 143, the decode logic may output 
either an Event Run signal on line 147 or an Event Suspend signal on line 148 to suspend logic 149 connected to the 
suspend pin by line 150. Alternatively decoding of the signal on line 143 may cause the decode logic 145 to output an 
Event Reset signal on line 151 to the CPU pipeline circuitry 152. Alternatively the decode logic 145 may output an 
Event Set Reset Handler signal on line 1 53 to the reset handler logic 154 together with the operand value on bus 1 56. 
[0057] Figure 1 6 illustrates the suspend logic 1 49. Lines 1 47 and 1 48 form inputs to an SR latch 1 57 which provides 
a second input 1 58 to an OR gate 1 59 having the suspend pin providing the other input 1 50. In this way the signal on 
line 147 is logically or-ed with the suspend pin to generate a fetch disable signal on line 160 which includes a latch 
161 providing the suspend flag. The signal on line 160 has the effect of inhibiting the fetching of instructions from the 
instruction cache 42. This eventually starves the CPU of instructions and the CPU execution will be suspended. As- 
sertion of the signal on line 148 will clear any previously asserted signal on line 147 in the normal operation of the SR 
latch 157. 

[0058] Figure 17 illustrates the reset handler logic 154. When the Event Set on line 153 is asserted, this is supplied 
to a reset handler state machine 162 connected to a register bus 163 interconnecting the reset handler register 119, 
shadow reset handler register 121 and the instruction pointer bus 112. The response to assertion of signal '153 is as 
follows: 

1 The state machine 162 asserts the read line 164 of the reset handler register 119 which causes the value in the 
reset handler register to be read onto the register bus 163. 

2 The state machine 162 asserts the write line 165 of the shadow reset handler register 121 causing the value on 
the register bus to be written into the shadow reset handler register. 

3 The state machine 162 causes the value on the Ev_hand!e bus 156 to be put onto the register bus. 

4 The state machine 162 asserts the write line 164 of the reset handler register 119 which causes the value on 
the register bus to be copied into the reset handler register 119. 

[0059] Alternatively if a get_iptr_sig is asserted on line 166 from the CPU pipeline 1 52 then the following occurs. The 
state machine 162 asserts the read line (R/W) of the reset handler register which causes the value in the reset handler 
register to be read onto the register bus. This value is transferred along the line labelled IPTR. 
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[0060] The following method may be used to boot one or other of the CPUs 12 or 13 of Figure 1 when the chip is 
connected to an external microcomputer through the port 30 similar to the arrangement shown in Figure 11. The two 
CPUs 12 and 13 may be connected to a common suspend pin 118. When pin 118 is asserted, after th hard reset pin 
46 has been asserted, both CPUs are prevented from attempting to fetch instructions. The external link 30 and external 

5 microcomputer 1 23 can then be used to configure the minimal on-chip state by writing directly to control registers on 
chip 11 and storing the necessary boot code into the DRAM memory connected to bus 33 of chip 11 . When the state 
of the suspend pin is changed one of the CPUs can boot from the code now held in the DRAM for the chip 11. To 
achieve this, the suspend pin 118 is changed to an assert state after a hard reset has been asserted. The external 
microcomputer 123 sends packets through the port 30 to write boot code into memory 120 shown in Figure 11 . The 

to host 123 then executes an instruction to send the special event EVENT SET RESET HANDLER to the selected one 
of microcomputers 1 2 or 1 3 and in this example it will be assumed to be CPU 1 3. This will provide a new target address 
in the reset handler register 119 for CPU 1 3. The host 113 will then execute an instruction to send through the port 30 
a special event EVENT SUSPEND to the other CPU 12, This will set the suspend flag 1 1 7 of CPU 1 2. The assert signal 
on the suspend pin 118 is then removed so that CPU 13 will start executing code derived from memory 120 from the 

*s target boot address held in the reset handler register 1 1 9. CPU 1 2 will remain suspended due to the start of its suspend 
flag 117. When it is necessary to operate CPU 1 2, it can be started by CPU 1 3 executing an instruction to send to CPU 
12 the special instruction EVENT SET RESET HANDLER. This will change the default boot address held in the reset 
handler register 119 of the CPU 12. CPU 13 must then execute an instruction to send the special event EVENT RUN 
to CPU 12 which will, as described above, start execution of CPU 12 with code derived from the address in the reset 

20 handler register 119 of CPU 12. 

[Q061J In this way the microcomputer of Figure 1 can be booted without the requirement of having valid code in a ROM. 
[0062] Although the above described boot procedure used boot code which had been loaded into the local memory 
1 20 for the chip 11 , the similar procedure may be followed using code located in the memory 125 which is local to the 
external microcomputer 1 23. To achieve this.Vie same procedure, as above, is followed except that the special event 

25 which is sent through port 30 to load the reset handler register 11 9 of CPU 1 3 will provide a target address for the boot 
code which is located in the address space of the port 30. In this way, when the assert signal is removed from the 
suspend pin 118, CPU 13 will start fetching code directly from the external computer and external memory. When CPU 

12 is needed it can be started by CPU 13 as previously described. 

[0063] By arranging for the host 113 to send the special instruction EVENT SUSPEND to CPU 12 prior to removing 
30 the assert signal from suspend pin 11 B it is possible to reduce the amount of instruction fetching through the port 30 
since CPU 1 3 may boot alone and then arrange for CPU 1 2 to boot rather than attempting to boot both CPUs 1 2 and 

13 from the external microcomputer through the port 30. 

[0064] Watchpoint registers may be used to monitor the execution of a program. These registers may be used to 
initiate a debug routine when a particular memory store is addressed or alternatively when instructions from a particular 
35 location are executed. 

[0065] Various examples of use of the chip 11 in a network having a plurality of interconnected chips are shown in 
Figures 11 to 14. 

[0066] In the example of Figure 11, the chip 11 is shown for simplicity with the single CPU 12 as CPU 13 is not 
involved in the operation described with reference to Figure 11. The chip is connected through the external memory 

40 interface and bus 33 to a memory chip 120 which is local to the CPU 12 and forms part of the local address space of 
the CPU 12. The port 30 is connected by two serial wires 121 and 122 to a further microprocessor chip 123 which in 
this case forms a debugging host for use with chip 11. Line 121 provides a unidirectional input path to chip 11 and line 
122 provides a unidirectional output path to the host 123. The host 123 is connected through a bus 124 to a memory 
chip 125 which is local to the host microcomputer 123 and thereby forms part of the local address space of the host 

4S microcomputer 123. In order to carry out debugging operations on the CPU 12, the host microcomputer may operate 
software derived on-chip in the microcomputer 123 or from its local memory 125 so that the host 123 causes special 
events, as previously described, to be issued in packets along the serial line 121 through the port 30 onto the P-link 
system 15. These may have the destination address indicating the CPU 12 so that this special event is handled as 
already described with reference to Figure 10. This may be used to suspend the CPU 12 at any time and to replace 

50 the value in its reset handler register and to reset the CPU 1 2 either from its previous state or from a new state indicated 
by the value in the register 119. The CPU 1 2 may have part of its address space located in addresses of the memory 
1 25 local to the host 1 23. The port 30 forms part of the local address space for the CPU 1 2 and consequently a memory 
access may be made to the address space allocated to the port 30 and in this case the response may be synthesised 
by software running on the host microcomputer 123. It is therefore possible to set the reset handler register 119 to be 

55 an address local to the host rather than local to the CPU 1 2. In this way a host can, independently of operation of the 
CPU 12, establish itself as the source of the instructions and/or data to be used by the CPU 12. This mechanism may 
be used to initiate debugging from the host 1 23. In the case of a chip 11 having two CPUs 12 and 1 3, it is possible to 
debug software running on CPU 12 as already explained while leaving software running on CPU 1 3 unaffected by the 
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shown h22 . 9 T ° Ut ° n CPU 12 ' ThiS iS the P ° sition shown in R 9 ure 12 «h«e the second CPU 13 is 

^S!T^V P 7r 8 n T a,,y in ° b,ainin9 inStrUCti ° nS ,ro(n fts instructfon °' from tt,e memo^ 
rme^ p To h , " 9 r ° Ut,ne ° perating on CPU 12 in injunction with the host 123 

0067] Figure 1 3 shows an alternative arrangement in which the network is generally similar to that described wi.h 
reference o F.gures 11 and 12. However in this case the CPU 12 is provided with a dalaTa E*?12S£S2 
a code wa chpomt reg.ster 1 31 in which respective addresses for data values or instruction Sons mTv be he ld so 

« J35? 3 deb . U9 r ° Utine 9 th0SS Wa,ChP ° intS are reached - ,n ,his exam P' e - *• host m^X i 23 can at 
any po.nt during the execution of a program by the CPU 12, briefly stop execution of the cm 12 and cl sa .h« 

S Jr^T^T' C ° mPUter archi,ec,ures watchpoint triggers are handled using a vector common to trans or 
^SJSHa U ? 0WS tf ! 8 S3m9 nS,WOrk 38 preVi0USly described with reference *> F>Bure 12 In this case the host 
™ ihtU™ \? T.l . ™ y e>ecuM ■»">«*»» Mich send special events lo the other CPU 

R?lh t ^? P °' nt debu 99 |n 9 ma V be ca ™° out without the need to use memory local to the on<*b Cp£ 

the path 1 5. The range of transactions covered by the packets are shown in the folbwing table. 



r 


Request 


Ordinary Response 


Transaction 


Opcode 


Packet Length 


Opcode 


Packet Length 


Load Word 


0x09 


8 


0x29 


11 


Load2 | 


OxOA 


7 


0x2A 


19 


Load3of4 


OxOB 


7 


0x2B 


27 
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(continued) 





Request 


Ordinary Response 


Tra n taction 


Opcode 


Packet Lenath 


Oocode 


Packet Lenath 


Load4 


OxOC 


7 


0x2C 


35 


StoreWord 


Oxll 


16 


0x31 


3 


Store2 


0x12 


23 


0x32 


3 


Store3of4 


0x13 


31 


0x33 


3 


Store4 


0x14 


39 


0x34 


3 


Swap 


0x19 


15 


0x39 


11 


Event 


0x01 


16 


0x21 


3 



[0073] This table shows in the left hand column the type of transaction which may be designated by the packet and 
will be identified by the Opcode 74 of each packet. A different Opcode and different packet length is used for request 
and response packets as shown in the above table. All transactions listed in the table are memory access transactions 

20 apart from the event transaction. Although Figure 7 showed a general form of response packet it will be understood 
that various transactions including the event transaction do not require data in the response packet. The response 
packet merely confirms to the source that the request packet was received. The memory, access transactions listed 
above includes ToadWord" which reads up to 8 bytes of data from a memory location. Load2 transaction reads 16 
bytes of data from a 16 byte aligned location in memory. Load3of4 transaction reads 24 bytes of data from a 32 byte 

2s aligned location in memory. Load4 transaction reads 32 bytes of data from a 32 byte aligned location in memory. The 
various "Store" transactions are the equivalent transactions for writing multiple bytes of data into memory. 
[0074] The event transaction may be a special event as already described. It may also be used to designate a normal 
event or interrupt. The request and response packets for LoadWord, StoreWord and Event are shown in Figures 21 
to24. Similar formats are used for the other transactions listed in the table above. Each includes a designation indicating 

30 byte for use by the P-router control 22 of Figure 1 to ensure that the correct device connected to the P-link 1 5 receives 
the packet which is put on the address and data path 15. Each packet includes the Opcode adjacent the destination 
indicator so that the recipient may decode the nature of the transaction required. Similarly each request packet has a 
TID indicator and source indicator as already indicated so that the recipient device may decode the packets according 
to a common format and provide response packets which also have a common format for decoding by the source of 

35 the request packet. 

[0075] In the case of the event transactions, the event request packet does not require the additional 3 bytes of 
address location provided in section 100 of Figure 6. Consequently the bit pattern used to identify the type of event 
(corresponding to the significant bits of the Event number referred to in connection with the event instruction) are 
located in section 100 used for additional address information in the other types of transaction. 

40 [0076] Each of the above transacting packets for use on the P-link 15 can be generated by a hardware operation 
such as the event logic in any of the modules or it may be generated in response to a software operation such as the 
execution of an instruction by the CPU. The format of the packets used on the P-link 15 is the same whether the packet 
is in response to a hardware operation or a software operation. The CPU 12 may execute an instruction such as an 
event instruction in order to directly generate a packet for use on the P-link 1 5. Alternatively it may execute an instruction 

45 which causes some other device to use hardware circuitry to generate a transaction packet of the type described above. 
In seeking instructions or data from the on-chip caches 42 or 43 it may be necessary to carry out a memory access 
operation in order to obtain data or instructions from memory which are not already in the respective cache. The cache 
control circuitry may then include circuitry similar to the event logic of the modules 14 so as to generate a memory 
access packet in response to the instruction execution by the CPU where the required instruction or data was not 

so already found in the cache. 

[0077] The instruction set of the CPU includes a plurality of load and store instructions corresponding to the various 
transactions listed in the table included earlier in the specification. The load and store instructions for memory accesses 
will generate a memory address using a base pointer with an index or offset. This will be used in the address portion 
of a request packet as previously described. The destination for such a packet will identify the interface of either an 

55 on-chip memory or an external memory. The type of instruction executed will determine the opcode of the packet. 
[0078] The transaction packets which are distributed on the on-chip P-link 15 may be output or input through the 
debug port 30 from an external chip in a network of the type shown in Figure 16.lt will be understood that the transaction 
packet will then be changed from an on-chip parallel form to a serial bit form (or to a less serial bit form than that used 
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indi^torTo! 9 !,?' 11 '! 0 " T hiP P "' ink 1 5) ' ThS Senal bit Packel " l 88 P revious, V described include •» Packet length 
8 S I Se "l transmiSS,on on 10 betwee n ^jacent chips. In the arrangement shown in Figure 

1L1 " etw ° rkcom P rises or more srmilar chips each having its own system of address and data path 15 with 

Z2 srrs ,v 5 a H nd cp tn 12 ; n ,h : s *■* ,he address space used 0,1 ^ * »» «« k^js 

2^ ^ 0ther ch, P * e network so that each P-link connected in the network provides part o. a commonly 
accessible address space. To d.sunguish between similar addresses on different chips, the P-router control 22 of eTch 

to a JZ!nfi t , T ^I?'" 9 addfeSSeS ,0r te OWn addressss while CPU ma Y enable access 

he ^Tdi ? T COrreS P° ndin 9 t0 a different chi P j " «*r to use a packet destination address which identifies 
the correct dest.nat.on on an interconnected chip accessible through the external port of the chip on which the source 

^ti^T ^'^T thS P ' Urali,y ° f intefCOnne cted chf P s ma * use a co ^°" tended addret space ac e s 

connecld 9609 " "* ^ * ****** idemi,yin9 3 WqU " ld deS,inati ° n ° n any inte '" 

Ss s^ n :r rrg set ,hese *" have a brt pattern extendin9 ° ver 2 b * es ■-«* *• - 



Name 


Bits 


Function -] 


EN. VIP 


0-4 


Virtual Interrupt Pin to deliver event to. 


EN.TYPE 


5-6 


0 Edge event J 

1 Level-on event j 

2 Reserved J 

3 Level-off event 


ENCODE 


0-14 


Special event code 


EN. 

SPECIAL 


15 


t£ ' *!! ™ ^ ,S 3 SpeC,al ° r SOft * reset eVent - ,f zero ' the event js a normal event so 
EN. VIP and EN.TYPE are valid but eventoperand is not used. If one, the event is a 
special or soft-reset event, and EN.CODE and the event.operand are valid 




16-63 


Destination CPU/Device event address. 



r22 23 ?f thJh« t ^ T ed : 38 PreVi ° US ^ deSCribed ' in ,he address secti °" 100 o{ »• Packet shown in 

bte M fSJUS 5I -' S th6n eVent iS 3 SpeCia ' EV8nt aS a,read y describ9d - « h °wever Ml 5 is zero then 

'ndioafed in 2 HfT' 1 ^! ?Z W " rupt t0 Which the ""W* «V *^ely respond As 

hi ? b,tS °' 4 ' nd,Ca,e 3 VirtUal in,errupt pin for use al the destination thereby indicating the 

Srln pJ ! V ?Jo BltS 5-6 indiC3,e Whe,hef the Event is res P° ns ^ to an edge detected event oTa level 

^26 Z in?" 3 3 T "J SUPPNed <0 VirtUa ' interrupt pin '°9 ic 175 * shown in more detaT.* 

iZ • P fpin? 8 TS3f r 1 i 4 r fed through a seiec,or 176 ,o a bank ^p^g ^ 

wS nin a h- f ho hi k r' nS ( haS 3 hard Wred Pri ° rity ,evel corre sponding to the number of the pins. In other 

words p.n 0 has the highest pnorrty referred to as priority 0 and pin 31 has the lowest priority 31 A register 178 holds 

.nterrupt p ns 177 to locate whrch p.ns now have an indication of an awaiting event. This encoder 179 then provides a 
l,nSl80 t toac Q °7 arator181 «hich compares the priority of any arriving mm^^J^SS^X 
She ncoTnnl er ^ ^ V ' P '° 9iC 1 75 ' 8 30,6 1 ° make a M ° decisi - d «Pen^ng on the pr io il 

pa k t or no Mf the orS " ? ^ ° PU Sh ° U ' d 3t th ' S time take aCtion to res P°" d * |S2 

Sister 7E tn 1 L,?h T- 179 ' nd ' CateS that inC ° ming eVent has hi 9 her P riorit V tha n that indicated in 
register 78 an event launch signal is provided on line 182 to the CPU pipeline 183 shown in Figure 25 The CPU 

of a transactron packet through a transmit buffer 185 connected to the P-link 15. The CPU pipeline 183 is also provided 

25^"!? 6 1 ° Pf ° Vide ^ identification of inst ™ tions tor « interrupt routine depending upon ^e sou ce ana 
dev.ee .den,,f,er of an event packet. If the VIP logic 1 75 determines that the CPU should respond to the Even! packet 
the Event decode log.c 172 provides on line 186 details of the source and device ID of L even pactet wSch fe 
supp ed on a control bus 1 87 to the CPU pipeline 183. This enables the CPU pipeline to u£^J^Jt££ 
lions forthe interrupt routineappropriatetothat source and device. Toenable the CPUlo ^^i^SHS 

TST^Th 6 T *• Pfi0rfty he ' d " the r69iSter 178 iS tra " Sferred int0 a ^ rio^ regis, r 87 
. ,1 Voi ■ f ' Pt r ° Utlne thS ° riginal Prbrity held in re 9 ister 167 can be reestablished in register 178 

ruotd ,h eL , P ' P " mUSt b ° ,h S3Ve the inStfUC,i0n P° inter and thread status w - d appropriate h lZ- 
rupted thread for use ,n resumpt.on of the thread after execution of the interrupt. These values are held in registers 
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188and189. 

[0081] In order to generate the event-packets in th event logic 8 of each modul shown in Figures 1 and 1 8, event 
logic and packet generator circuitry of the type shown in Figure 27 is used. A packet buffer 190 is arranged to output 
a packet onto the P-link 15 via interconnection 1 91 when the packet has been assembled. Th event bgic will include 
a signal level or edge detector 1 93 in order to initiate the generation of an event packet. The particular device or module 
in which the event logic is located will store in a register 1 94 details of the source and a device identifier for the particular 
device at the source which is giving rise to the event packet The module will also include in register 195 details of the 
destination address for any event packet generated by that module. Register 196 will hold details of the event trans- 
action which will be requested by that device. It will have the bit pattern necessary to decide whether the event is a 
special event or a normal event and in the event of a normal event it will provide the event priority and event type. If 
that module is providing a special event, then an operand may be needed and this will be held in an operand register 
1 97 for concatenation in an operand section of the packet buffer 1 90. If the device or module is also required to produce 
a memory access transaction packet then buffer 202 will operate under a control unit 1 98 to locate in the packet buffer 
190 an indication of the memory access transaction rather than an event transaction. The device may well output more 
than one request packet prior to receiving any response packet. For this reason a counter 1 99 is provided to count the 
number of packets output and it also receives an input of the number of response packets received by buffer 200. The 
connection of event transaction data or memory access transaction data into the packet buffer 191 is controlled by a 
selector 201 controlled by the control unit 198. The contents of the registers and function of the control unit 198 will 
be determined by the particular implementation of the transaction packet generating circuitry at any particular device 
or module. 

[0082] The invention is not limited to the details of the foregoing example. 
Claims 

1. A computer system including an integrated circuit chip with an address and data path interconnecting a plurality 
of on-chip devices including at least one CPU, at least one module and a memory interface, (a) said module having 
packet generating circuitry responsive to an event to generate an event request packet including a destination 
address : (b) said CPU having event logic to decode the packet and identify the request of the packet, and circuitry 
to generate addressed memory access packets, and (c) said address and data path being used for distribution of 
both event request packets and memory access packets. 

2. A computer system according to claim 1 in which both said module and said CPU each include packet generating 
circuitry operable to generate both event request packets and memory access packets for distribution on the com- 
mon address and data path. 

3. A computer system according to claim 1 or claim 2 in which the packet generating circuitry is responsive to receipt 
of an event request packet to generate an addressed response bit packet for distribution on said address and data 
path. 

4. A computer system according to any one of the preceding claims in which the packet generating circuitry of a 
module includes means to indicate the address of the destination for the packet as well as the address of the 
module acting as a source of the packet. 

5. A computer system according to claim 4 in which the packet generating circuitry is responsive to receipt of an 
event request packet to determine from the packet a source address of the packet and to generate a response 
packet using said source address as the destination indicator for the response packet. 

6. A computer system according to any one of the preceding claims including an on-chip memory, said memory 
interface providing connection between said address and data path and said on-chip memory. 

7. A computer system according to any one of the preceding claims including an off -chip memory, said chip having 
an external memory interface connected to said off-chip memory and to said address and data path. 

8. A computer system according to any one of the preceding claims in which the packet generating circuitry of said 
module is arranged to generate an event request packet forming an interrupt request with a priority indicator and 
said event logic of the CPU includes comparator circuitry for comparing priorities of event request packets received 
with the priority of any current CPU activity. 
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9. A computer system according to any one of claims 1 to 7 in which the packet generating circuitry of said module 
is arranged to generate an event request packet in the form of a control packet for control command to the CPU. 

10. A computer system according to any one of the preceding claims in which a plurality of modules are provided on 
chip, each having packet generating circuitry for generating event request packets, at least one module being 
arranged to generate event packets in the form of prioritised interrupt requests and at least another module being 
arranged to generate event request packets in the form of control packets for the CPU. 

11 . A computer system according to any one of the preceding claims in which said address and data path includes at 
least one on-chip bus arranged to distribute said packets in bit parallel format. 

12. A computer system according to claim 10 wherein said integrated circuit chip includes at least one external port 
for off-chip connection, said port including bit format translation circuitry to convert on-chip packets of bit parallel 
format to a less parallel format for transmission off -chip. 

13. A computer system comprising at least two integrated circuit chips, each as claimed in any one of the preceding 
claims, the two chips being connected through external ports to allow communication between the address and 
data paths of the interconnected chips. 

14. A method of operating a computer system comprising an integrated circuit chip with an address and data path 
interconnecting a plurality of on-chip devices including at least one CPU, at least one module and a memory 
interface, which method comprises detecting an event at a module, generating an event request packet with a 
destination address, distributing the request packet on the address and data path to the destination, decoding the 
packet at the destination to identify the nature of the request, said method further including generating addressed 
memory access packets for memory read and write operations, said memory access packets and said event re- 
quest packets being distributed on the same address and data path. 

15. A method according to claim 14 wherein event request packets are generated for distribution on the address and 
data path to the CPU, which event request packets are in the form of prioritised interrupt requests. 

16. A method according to claim 14 or claim 15 in which event request packets are generated for distribution on said 
address and data path to the CPU, at least some of said event request packets being in the form of control command 
packets to which the CPU must respond on receipt of the packet. 



15 



EP 0 959 411 A1 




16 



EP0 959 411 A1 



r 



a 



LU 

CD 
Z 
LU 



2 

CL 



3 



CM 



W3snvib3s-3a 



r 



■8 



U3snviu3s 



<UJZ 



O 



3 



.in 



CO 

cvj 



00 

LU 
LL 
LL 

is 

o£ 

Zh 
LU 

a 
< 



CO! CO 2 

"teg 

LU 



S3 



UJ 




30Vdd31NI MNlTd 




HlVd VIVQ XNlTd 



lOdlNOO HNII-d 



17 



EP 0 959 411 A1 



Rg.3. 

TRANSFER 




P-LINK 
PACKET 



8 

93 



\ 



J 

jSHIFT REGISTER U-, 



PORT STATE MACHINE ^VwW 

REGISTER BANK 



ST "ATE 

MACHINE SERIAL LINK 

91 PACKET 



~JW 1 

VREADfADDR 



Fig.4. 

REGISTER BANK 
PORT STATE MACHINE 90 WRITE 

72 93^ DA 7 A VREAD1ADDR 

'\ P-LINK ft/l L - L ' - 

\ PACKET 1 



50 



STATE 
MACHINE 



91 




SERIAL LINK 
PACKET 



TRANSFER BUS 



SHIFT REGISTER] -*- 
f ~8 ^0 



71 



18 



EP 0 959 411 A1 



Fig.5. 
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